1. Field of the Invention
The present invention relates to Virtual Machine technology.
2. Background Art
With Virtual Machine (VM) technology, a user can create and run multiple operating environments on a server at the same time. Each operating environment, or Virtual Machine, requires its own operating system (OS) and can run applications independently. The VM software provides a layer between the computing, storage, and networking hardware and the software that runs on it.
Virtual Machine technology can lower information technology (IT) cost through increased efficiency, flexibility, and responsiveness. Each VM acts as a separate environment, which reduces risk and allows developers to quickly re-create different operating system (OS) configurations or compare versions of applications designed for different OS's. Additional customer uses for VMs include targeted production server consolidation, hosting of legacy applications (older versions), and computer or server backup.
A Virtual Machine technology is therefore one technique for emulating or otherwise virtualizing the behavior of software and/or hardware. Generally, a Virtual Machine is an environment that is launched on a particular processor that is running an operating system. Normally, the operating system installed on such a machine or processor has certain privileges that are not available to user applications. For example, many input/output commands may be privileged, and executable only in the operating system (or privileged) mode. Certain areas of memory, or certain addresses in memory, also may require operating system privilege to be accessed.
A frequent situation that arises in this context is the problem of emulating (or, more broadly, virtualizing) a different operating system on the same processor. For example, with one version of Microsoft Windows running on the Intel x86 processor (for example, in a server environment), it may be necessary to emulate the behavior of another (different) version of Windows on the same Intel processor. This second operating system is generally referred to as “Guest OS,” and the code that it executes is generally referred to as “guest code.” Note that in order for the emulation to be meaningful, the Guest OS needs to execute privileged instructions as if it were actually running on the processor. In other words, the Guest OS, running as a Virtual Machine, is itself unaware that it is a Virtual Machine.
Execution of such privileged instructions, however, is the province of the native operating system. Therefore, any attempts by the Guest OS inside Virtual Machine to execute privileged instructions must be intercepted, so that they can be properly executed (or otherwise handled) by the VMM. The component that is responsible for this interception and emulation of privileged instructions is called a “Virtual Machine Monitor” or “VMM.”
A typical Virtual Machine Monitor (VMM) enables a single physical machine or processor to act as if it were several physical machines. A typical VMM, under control of a high-ranking operating system (OS), can run a number of different operating systems simultaneously, such that each of these different operating systems is its own Virtual Machine.
In other words, the Virtual Machine Monitor can handle one or a number of Virtual Machines, each of which represents its own operating system, and each of which can run its own application software. Usually, in industry parlance, the high-ranking OS is referred to as a “host OS” (HOS). The multiple operating systems that are running as Virtual Machines are usually referred to as “guest operating systems” (“Guest OS's”) running “guest code.” At the present time, there are two conventional mechanisms for structuring VMMs: a non-hosted VMM, and a hosted VMM.
In the case of the non-hosted VMM, which is shown in FIG. 1, the VMM itself is a full-fledged operating system. Such a non-hosted VMM includes drivers for controlling and managing input/output activities of the physical computer. The non-hosted VMM is installed onto a “bare” PC, and has a monopoly on control over the I/O devices. This type of VMM exists at the system level, and can create any number of Virtual Machines that do not exist at the system level, and which cannot directly work with input/output devices. Such a VMM, therefore, needs to manage CPU scheduling and resource sharing for the Virtual Machines. An example of such a VMM is the IBM ESA/390.
The non-hosted VMM have several problems. One problem is complexity. Apart from virtualization, it must also manage I/O device handling, memory handling, scheduling and so on. Such a VMM therefore needs to be designed as a full-fledged operating system with additional virtualization support. Another problem is poor compatibility. Due to a very large spectrum of available hardware and I/O devices, it is almost impossible to support all possible PC configurations for such a VMM. Therefore, such a VMM is usually limited to supporting a small set of possible (predefined) hardware configurations. In any event, a non-hosted VMM cannot normally work directly with all the I/O hardware. An additional problem is a large footprint and having to include third-party code (device drivers, and so on) that run on the system level—this can seriously affect overall system stability and security.
In the case of the hosted VMM, which is shown in FIG. 2, the VMM itself is not a full-fledged operating system. Such a VMM does not include device drivers, and cannot control hardware devices, such as I/O devices, directly. Such a hosted VMM is installed into the host operating system (HOS), and uses HOS's API (application programming interface) to work with the I/O devices. Both the VMM and the host operating system have system-level privileges, and exist on a physical computer concurrently. The VMM is responsible for preserving the context of the host operating system when switching from the HOS to the VMM, and is responsible for restoring the context of the HOS when switching back to the HOS. The hosted VMM creates any number of Virtual Machines, none of which have system-level privileges, and none of which can work with I/O devices directly. The VMM either emulates the input/output devices for the Virtual Machines, and uses the HOS to work with the real I/O devices.
For each VM, a separate process is created, and the HOS is responsible for scheduling of both the VMs and other processes in the HOS. Examples of such hosted VMMs include VMware GSX Server, VMware Workstation, MS Virtual PC, MS Virtual Server and SVISTA 2004.
Hosted VMM also have a number of problems. One such problem is poor security. A non-hosted VMM is well protected, because all its VMs run without system privilege level and cannot harm the VMM and any other VM. If one of the VMs were to crash, it will not affect the VMM nor any other VMs. For the hosted VMM, a crash of the HOS can damage both the VMM and all other VMs. Also, it can be inefficient or even impossible for hosted VMM to use hardware virtualization technologies in new families of processors, such as, for example, Intel's Virtual Machine Extension (VMX) technology.
Accordingly, what is needed is a way to combine the best features of non-hosted VMMs and hosted VMMs to support an efficient virtualization.